干了十多年零售软件，我越来越觉得，技术好不好，得看能不能让店员少骂娘。做零售信息化的同行大概都听过那种抱怨：“明明系统里显示有货，货架上偏偏空着；总部刚调拨过去，门店说没收到。”这种库存割裂的毛病，在连锁门店一多起来就成了绝症。我所在的是一家土生土长的软件系统公司，团队核心基本都是从国内早期ERP项目里滚打出来的。去年秋天，一家拥有四百多家社区药房的客户找上门，抛出一个颇有点颠覆的要求：别给我们配扫码枪了，店员用自己的手机，扫一扫就能入库出库，而且所有门店的库存得在秒级互相看见。
这活儿接得不容易。工业扫码枪贵是不假，但皮实、识别快。手机摄像头受光线、角度影响大，而且店员流动性高，手机型号五花八门。不过客户算过账，四百家店如果每店两台枪，采购加维护一年小十万没了。我们作为本土服务商，最明白这种中小微连锁的痛，咬咬牙立项。
前端我们交给了微信小程序。这里头不是调个 wx.scanCode 就完事的。我们底层用了微信原生的 camera 组件自己做图像帧捕获，集成了开源的 ZXing 并做了本土化训练——比如针对药品追溯码那种极密排版做了识别优化。更关键的是离线优先策略：门店地下室库房没信号？小程序把扫码记录暂存 IndexedDB，网络恢复后差分同步。这个细节，后来被客户评为“最实用的设计”。比起那些洋方案，我们清楚国内药店的GSP规范多严，知道便利店店员文化程度参差，界面不能搞极简抽象，所以按钮做得比老年机还大。
后端架构才是真考验。我们坚决摒弃了老一套的单体 WAR 包，全面转向微服务。技术选型上，采用 Spring Boot 2.7 配合 Spring Cloud Alibaba 2021 版，注册配置中心统一用 Nacos 集群，保障异地多活。按照领域驱动设计（DDD），我们把系统切为门店域、商品域、库存域和身份域。库存域内部又分命令服务和查询服务，明摆着走了 CQRS 模式——写操作由库存命令微服务处理，强事务落库；读操作则依赖 RocketMQ 的事务消息，将库存变更事件广播给各区域的查询微服务，后者用事件溯源（Event Sourcing）方式更新本地物化视图。
这么绕一圈，图啥？就为了实时同步还不掉链子。举个例子：广州某店手机扫码卖出一盒阿莫西林，小程序请求直达网关，库存命令服务校验后扣减，同时发 MQ 消息。上海店的查询服务订阅到消息，几乎同时（实测平均延迟 600 毫秒）更新了那盒药在总仓可视库存里的数字。总部运营盯着大屏，再不会出现昨天卖的今天才看到的尴尬。为了满足国内监管留痕要求，我们特意把审计日志服务独立出来，每次库存变动全链路染色，等保三级轻松过。
高并发场景我们也压过测。用全链路压测工具模拟双十一凌晨五百家店同时盘点，Sentinel 熔断规则扛住了瞬时每秒 1.2 万笔扫码请求，微服务自动扩容，没崩。这要是放在以前的紧耦合系统，数据库早死锁了。
项目上线九个月，客户盘点人力砍掉一半，库存准确率从 92% 蹿到 99.7%。最让我们自豪的是，整套系统跑在国产信创云上，数据完全自主可控。有回半夜系统告警，我们本地工程师十分钟连上客户环境，发现是某店员手机时间不对导致签名失败，远程指导校正，没误早班营业。
回头看，手机当扫码枪绝非赶时髦。没有扎实的微服务底座，这方案就是空中楼阁。本土公司做这类项目，优势恰恰是懂业务泥土里的细节，能用熟的技术栈，缝出合身的衣服。连锁门店的数字化，说到底，得靠我们这些在机房闻过灰尘的人，一行行抠出来。
微信号：18581869297
